前言

這篇是個非常general的議題，關於從錯誤中學習，適合所有的工程師看。如果你常遇到工作上把意外怪罪為人為失誤的話，特別可以看看，對於這些人為失誤的意外，我們如何從中學習。

P.S. 這篇所有的演講資料都可以從講者的github上找到：learning from incidents

演講總結

演講想探討的問題是：我們如何從意外事故（incident）中學習？與從意外中學習的正確姿勢。

為何要從意外中學習？

簡單的回答是：「因為我們想避免意外發生。」但我們真的有辦法100%避免意外嗎？

講者表示「對於我們使用的複雜系統們，沒有100%不會出錯的」。原因是因為系統的運作永遠都與人為操作有關，沒有系統是不需要人為介入的。與其說人在操作系統（on system），不如說人其實是系統的一部分（in system）。

所以重點其實不在於避免所有意外發生，更多是我們要衡量災難本身帶來的影響，與我們是否能夠承擔災難帶來的後果。在公司裡常常會有的狀況是，我們花了很大的心力去避免意外產生，但是卻導致我們操作越來越複雜或越來越難管理。

常見謬誤

上面說了因為人是系統的一部分，所以人所用的語言去描述意外本身，也會大幅影響我們對意外的看法，進而影響我們能從意外中學到的事情。

所以下面列出四個常見的意外檢討的謬誤：

1. 歸因於人為操作失誤（Attribution to "human error"）

   「人為操作失誤」往往是個標籤，讓我們停止研究意外，因為大家會想說既然是人為操作失誤那就無法避免了。

   但事實是，人當然會犯錯，但系統設計、組織、個人因素與天時地利都有可能影響到人犯錯。所以往往在意外發生當下，人不會覺得自己是犯錯的。

   所以當我們聽到「人為操作失誤」，我們更應該深入探討問題而非就此打住。

2. 反事實的討論（Counterfactual reasoning）

   人們往往會在討論中出現類似這樣的言論：「如果當初...那應該就可以避免問題」「...沒有做...所以...」。但討論「沒發生的事情」無法真正解決問題，我們應該聚焦在「發生的事實」上。

   所以你不該說「這bug沒在testing中偵測到」，而應該說「這個bug要怎麼樣才能在testing中被偵測到？」

3. 標準的語言（Normative language）

   事後諸葛總是最容易的，我們往往會從結果來看當初應該做的最佳決定為何，但是當你是做決定的人時，你哪知道哪個是最佳決定= =。

   所以我們其實應該多問決策者，事發當下有哪些現象與環境來幫助他做出這個決定。

4. 機械問題的討論（Mechanistic reasoning）

   我們在尋找系統問題時，往往會去找到底是哪個元件（component）有問題。一旦發現沒有component有問題我們就停止尋找問題了。但了解元件的問題不足以了解意外的全貌。

面對意外該如何學習？

接下來要講講如何從意外中學習，此處的細節可以從作者的github repo看到。

這裡是站在一個協調者（facilitator）的角度來看這件事，而不是管理者的角度。而這個協調者不能是利益關係人，才能保持中立。（這裡有個Debriefing Facilitation Guide，可以參考如何當個好的協調者。）

1. 事後檢討（post-incident review）

   我們常常叫意外處理者或負責人自己寫incident report，但這其實這是不足的。

   最好是舉辦一個一個小時左右的post-incident review，大家一起來還原事件發生當下的狀況。記住，重點不是要找出「正確的作法」而是還原當下情境。

2. 問正確的問題

   不要問why而是問how，因為問Why會讓別人覺得被究責。而每個事件參與者對事件都有不同的體驗，專注於理解這些體驗與分享經驗，而非決定哪些是「正確的」。

3. 詢問事情要如何才不會出錯

   當蒐集完與理解既有的事實之後，嘗試去想需要哪些跡象、工具、技巧是可以幫助人做好決定的。因為做出不恰當的決策通常是因為資訊量不足，所以協調者的工作就是要找出中間資訊量的差異，並看用哪些方式可以彌補中間的隔閡。

4. 分開Review與Planning會議

   Review指的是事件回顧，而Planning指的是討論下一步與修正錯誤的討論。

   一方面是兩者的目標不同，所以可以讓兩個會議分別專注在How與Next step上。也有更多時間可以沈澱找出更好的改進方向。

   而Planning的會議就就不需要牽扯太多人，可以盡量的短跟快速就好。

   另外Review會議最好是不要manager來參加，因為可能會害意外負責人噤聲。而Planning會議就是manager可以參加的。

講者也說到，當然做這件事情的成本蠻高，大家不見得會願意花時間在這件事上面。因此可以先從找那些有趣，且不那麼重大的意外中開始練習做起，等大家對這個方式建立自信之後再慢慢的rollout出去。

個人心得

在聽這篇演講的時候，我完全就想到電影《薩利機長：哈德遜奇蹟》的情節。故事中主角機師Sully駕駛的飛機因為引擎故障，而導致他必須迫降飛機在河上，雖然被喻為英雄的拯救了所有乘客，但也被調查人員指責說做了不恰當的決定。調查委員會認為整件事是機師的疏失，因為他當下有更好的選擇可以迫降在另一個機場，並且就模擬結果來說也是辦得到的。但Sully表示那是不切實際的，因為模擬人員是在已知要如何反應的狀況下操作，但對他來說卻是要花時間來回檢查與做出決定才能得出當下的結論。

整個故事儼然就是這篇演講的精隨：我們不該用結果去反推當下要做什麼決定才是正確的，因為往往當事者在做決定的時候是沒有足夠的訊息的。與其事後諸葛給出「最佳解答」，不如去還原現場與思考從資訊不足的情況如何找到解答，才會真正的獲得進步。

預防問題的成本效益

另外演講裡有提到：我們往往會為了阻止某個問題的發生，而複雜化我們的流程。並不是說不該阻止問題發生，更重要的是我們要去評估「我們在阻止問題發生上所需要花費的精力」與「事情真的發生要修正他花費的精力」是不是成比例的。

之前就有過Ops（operators）因為不太信任我們的系統，所以提出需求希望我們多產一兩個report來讓他們做交叉比對資料正確性。可以理解他們的初衷，但是產report的effort其實很大，加上又會多一件事要來maintain，對他們來說也需要多出人力來檢查，更重要的是，產生report的部份基本上一年來也沒有壞過...，如果真的要做那就是為了做而做的而已。這就是「花費力氣避免問題產生」的效益與「出問題的影響」不成比例。

追根究柢真的好嗎？

雖然這篇演講是在講述追根究柢的必要性，但我並不認同所有事情都必須要找到root cause。原因是因為資源是有限，無論是人或時間或精力都是。

相信各位工程師們都有慘痛debug經驗，大部分時候寫feature其實不難，難的是debug或找出問題所在。很多時候我們尋找問題的root cause所花費的時間已經遠遠大於問題產生的可能性了，那我們還應該繼續查下去嗎？例如說每個月會有十幾個訂單會有奇怪的行為發生，而我已經花了兩天的時間尋找了各式各樣的log跟看了code但是都找不到問題，是否還有必要繼續花時間下去？

我自己覺得這一切都跟資源分配與成本效益有關，你花月多的時間在這個bug上你的邊際效益就越低。當然如果是個嚴重的問題絕對是必須要查出來的，但是大部分狀況下問題其實並不是那麼的嚴重，所以要謹慎考慮是否要繼續投資時間下去查出問題根源。

批判性思考與意外的全局性

演講也提到：知道出問題的元件在哪並不代表你知道意外的全貌。

在公司裡之前就會出現一些奇葩的狀況是，線上有個bug，而我們為了快速修正所以生了一個report來去讓OPs（operators）去手動修正這些數字。相安無事過了一陣子後，某天你接到一個request說這個report沒考慮到某個狀況要把特殊狀況考慮進來。來來回回幾次之後發現原本只是workaround（=暫時解決某個問題的應變方法）的report，卻變成正式的report了，OPs還甚至多花了個人力去做這件事。但實際上應該要做的是：修正原本的bug阿RRRR，如果沒有這個bug的話根本就不用這些report了。

我們花了一堆心力去東補西補某個系統會產生的毛病，但是卻沒想過本身這個系統的設計就是造成這些問題的根本。所以竊記不要看到一點病徵就嘗試解決他，確認已經了解事情的全貌再去討論下一步。